ESD-TR-66-281 


SYNERGETIC  MANAGEMENT  OF  COMPLEX 
MILITARY  SYSTEMS 

Milton  V.  Ratynski 


May  1966 


TECHNICAL  REQUIREMENTS  AND  STANDARDS  OFFICE 

ELECTRONIC  SYSTEMS  DIVISION 

AIR  FORCE  SYSTEMS  COMMAND 

UNITED  STATES  AIR  FORCE 

L.  G.  Hanscom  Field,  Bedford,  Mass. 


Distribution  of  this  document 
is  unlimited. 


vy 


^  I 


I 


ESD-TR-66-281 


SYNERGETIC  MANAGEMENT  OF  COMPLEX 
MILITARY  SYSTEMS 

Milton  V.  Rotynski 


May  1966 


TECHNICAL  REQUIREMENTS  AND  STANDARDS  OFFICE 

ELECTRONIC  SYSTEMS  DIVISION 

AIR  FORCE  SYSTEMS  COMMAND 

UNITED  STATES  AIR  FORCE 

L.  G.  Hanscom  Field,  Bedford,  Mass. 


Distribution  of  this  document 
i  s  un  I  imi  ted. 


FOREWORD 


Information  contained  In  this  document  was  presented  by  the  author 
and  published  in  the  1966  IEEE  International  Convention  Record, 
March  21-25,  1966. 


REVIEW  AND  APPROVAL 


This  technical  report  has  been  reviewed  and  is  approved. 

Ojju.  u  /vCw.//^-a 

FRANK  E.  BRANDEBERRY,  Colonel,  USAF 
Chief,  Technical  Requirements 
and  Standards  Office 


ABSTRACT 


This  paper  highlights  the  organization  of  a  creative  technology — System 
Engineering  Management.  A  new  Air  Force  Systems  Command  Manual^ 
describes  the  importance  of  TOTAL  SYSTEM  DESIGN,  in  which  it  is 
recognized  that  the  successful  design  of  a  complex  military  system  is 
fundamentally  dependent  upon  the  complementary  interplay  between  all 
the  technical/managerial/support  specialists  and  disciplines.  The 
procedures  summarized  herein  are  the  engineering  management  standard 
for  all  future  system  acquisition  programs  and  projects  by  the  Air  Force. 


SECTION  I 


INTRODUCTION 

In  recent  years,  increasingly  complex  military  systems  have  been 
designed  and  developed.  During  this  time,  there  has  been  an  emerging 
awareness  of  the  need  for  and  the  importance  of  TOTAL  SYSTEM  DESIGN. 
Groups  of  specialists  emphasizing  reliability,  maintainability,  facilities, 
safety,  human  performance,  system  testing,  etc.,  have  forced  a  recognition 
that  a  system  does  not  consist  of  equipment  alone. 

The  word  "system"  has  come,  through  practice,  to  include:  prime 
mission  equipment;  computer  programs;  equipment  for  training,  checkout, 
test,  and  maintenance;  facilities  required  to  operate  and  maintain  the 
system;  selection  and  training  of  personnel;  operational  and  maintenance 
procedures;  instrumentation  and  data  reduction  for  test  and  evaluation; 
special  activation  and  acceptance  programs;  and  logistics  support  for  test, 
activation,  and  operational  aspects  of  the  program. 

All  parts  of  a  system  must  be  synergetic  and  have  a  common  unified 
purpose.  This  absolute  necessity  for  coherence  requires  an  organization 
of  creative  technology  which  can  lead  to  the  successful  design  of  a  complex 
military  system.  This  organized  creative  technology  is  termed  by  the  Air 
Force  as  System  Engineering  Management.  System  Engineering  encompasses 
and  thus  replaces  terms  such  as:  systems  approach,  systems  analysis,  system 
integration,  functional  analysis,  system  requirements  analysis,  reliability 
analysis,  task  analysis,  maintenance  analysis,  system  definition,  and  team 
development  method. 


System  Engineering  Management  is  fundamentally  concerned  with  deriving 
a  coherent  total  system  design  to  achieve  stated  objectives  and  recognizes 
the  predominent  and  highly  complementary  role  played  by  engineering 
design  specialists  in  satisfying  total  system  design  requirements  and  the 
interplay  between  the  system  engineers  and  the  engineering  design 
specialists. 

System  engineering  per  se  is  not  new,  however,  the  formalizing  and 
standardizing  by  the  Air  Force  upon  a  particular  approach  is  new. 

Industry  and  government  organizations  will  have  ample  opportunity  to 
become  intimately  familiar  with  the  AFSCM  375-5  concept,  as  new  con¬ 
tracts  are  awarded.  In  this  short  paper,  it  will  be  possible  only  to 
introduce  the  scope,  describe  the  concept,  and  hopefully,  to  encourage  a 
much  more  thorough  study  by  the  reader. 
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SECTION  II 


THE  AIR  FORCE  SYSTEM  LIFE  CYCLE 

The  primary  purpose  of  this  paper  is  to  highlight  the  Air  Force  system 

engineering  management  technique,  however,  there  is  an  overall,  master 

management  technique  that  will  be  briefly  described  first,  the  Air  Force 
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375  System  Management  Technique. 

Air  Force  Systems  Command  Manual  AFSCM  375-4,  "System  Program 
Management  Manual,  "  describes  the  details,the  activities  and  events  that 
new  Air  Force  systems  will  be  required  to  establish  and  to  be  subject  to 
during  the  life  cycle  of  the  system.  The  total  life  cycle  of  a  system 
program  is  divided  into  four  phases — conceptual,  definition,  acquisition, 
and  operational.  The  overview  in  Figure  I  provides  a  context  within  which 
specific  elements  may  be  placed. 

The  Conceptual  Phase 

The  most  Important  objective  of  the  conceptual  phase  is  to  develop 
total  system  and  program  requirements  from  a  broad  system  objective  or 
mission.  These  requirements  serve  as  the  technical,  economic,  and 
military  basis  necessary  for  a  decision  to  develop  the  system  and  as  the 
technical  and  management  inputs  for  contract  statements  of  work  and  for 
the  system  design  process. 
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CONCEPTUAL  PHASE 


Feasibility  Studies 
SPO  Cadre  established 
4 Preliminary  Technical 
Development  Plan 
prepared 

System  Objectives 
developed 

Trade-Off  Analysis 
Technical  Approach 
established 


DEFINITION  PHASE 


SPO  established 
Definition  Contractor (s) 
selected 

System  design  specifica¬ 
tions  developed 
Design  trade-offs 
Specific  approach  selected 
Mgmt  plans  developed 


ACQUISITION  PHASE 


Development/Engineering 
Contract  awarded 
Detail  designs  completed 
Logistics/support  plans 
activated 

Equipments  produced 
Engineering  Inspections/ 

Cat  I,  II  Tests 
Conducted 

First  Operating  Unit  Accepted  Last  Article  Delivered 

OPERATIONAL  PHASE 


Category  III  tests 
conducted 

Necessary  re-designs 
initiated 

Maintenance,  logistics, 
support  actions  com¬ 
pleted 

System  turned  over  to 
user  or  modified, 
as  required 


Figure  I 

New  Air  Force  System  Life  Cycle 


The  conceptual  phase  is  generally  accomplished  in-house  by  DOD,  Air 
Force,  and  the  Systems  Division  concerned,  although,  on  occasion, 
preliminary  system  design  studies  are  awarded  to  industry.  The  not-for- 
profits  are  also  active  at  this  point  in  time  assisting  in  the  development  of 
detailed  objectives,  performing  major  trade-off  studies,  and  development 
of  the  preliminary  plans  for  higher  headquarters  review  and  approvals. 

Before  a  system  may  enter  into  the  Project  Definition  Phase,  the 
following  seven  prerequisites  must  be  satisfied. 

-  Engineering  (not  experimental)  effort  is  required. 

-  Technology  &  building  block  components  are  in  hand. 

-  A  thorough  trade-off  analysis  is  completed. 

-  The  best  technical  approach  is  selected. 

-  Mission  and  performance  are  defined  and  optimized  for  technical 
feasibility  and  cost  effectiveness. 

-  Cost  and  schedule  estimates  are  credible. 

-  Cost  effectiveness  of  the  proposed  system  is  favorable  over  other 
DOD  dollar  competition. 

The  Definition  Phase 

The  issuance  of  a  system  definition  directive  by  Hq  USAF  signifies  the 
start  of  the  definition  phase. 
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Department  of  Defense  Directive  3200.9  states: 

"The  most  important  objective  of  the  Definition  Phase  is  to  provide  an 
adequate  basis  to  assure  that  management  decisions  to  proceed  with,  cancel. 
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or  change  development  projects  are  made  on  a  total  system  and  total  cost 
basis.  This  basis  should  include  realistic  cost  and  schedule  estimates  and 
achievable  performance  specifications  backed,  in  the  case  of  contractor- 
conducted  Project  Definition,  by  a  firm  fixed-price  or  fully  structured 
incentive  proposal  for  the  Acquisition  Phase." 

The  definition  phase  is  normally  conducted  on  a  fixed-price  basis  by 
two  or  more  competitive  contractors.  The  competition  is  to  be  in  terms  of 
system  concept,  design  approach  (including  solutions  to  major  trade-offs), 
technical  and  management  planning,  and  overall  cost  and  schedule.  The 
winning  contractor  will  normally  be  awarded  the  full  scale  development 
contract.  The  definition  phase,  therefore,  is  the  period  preceding  full 
scale  development  during  which  system  engineering  and  technical 
management  planning  for  acquisition  are  accomplished. 

The  Acquisition  Phase 

This  is  the  period  during  which  the  detailed  engineering  is  accomplished, 
the  equipment  is  fabricated,  and  technical  validations  are  made  to  deter¬ 
mine  whether  the  contractor  has  met  specification  requirements.  The 
acquisition  contractor  is  required  to  perform  in  accordance  with  the 
system  performance  and  the  end  item  detailed  specifications  that  were 
developed  during  the  definition  phase. 

The  acquisition  phase  is  also  the  direct  opportunity  for  the  "customer" 
(the  using  agency)  to  participate  in  those  tests  and  evaluations  and  decide 
whether  he,  the  "customer"  will  accept  the  first  operating  units  for 
operational  use. 
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Air  Force  Systems  Command  Management  Manuals 


The  AFSC  Manuals  are  the  medium  through  which  Air  Force  directives, 
regulations,  dictums  and  requirements  are  put  into  practice.  There  is  a 
master  scheme  and  a  specific  usage  for  each  manual,  in  that  some  are 
intended  for  Air  Force  usage  only,  while  others  are  applied  selectively  as 
required  on  specific  contracts.  Figure  No.  2  summarizes  those  of  prime 
interest  to  industry.  The  manuals  are  all  cross-referenced  extensively  in 
order  to  eliminate  conflicts  and  double  standards.  Additional  information 
relative  to  those  manuals  that  have  a  major  impact  upon  contractors  follows. 

AFSCM  375-3,  System  Program  Qtfice  Manual 

375-3  describes  what  a  SPO  is,  how  it  is  organized,  how  the  overall  job 
is  done,  the  general  responsibilities,  the  relationships  with  other  government 
agencies,  and  the  functional  duties  and  responsibilities  of  all  the  members  of 
a  SPO.  375-3  is  introductory  and  indoctri national  in  nature  and  will  never 
be  applied  on  a  contract  as  a  requirement,  but  is  of  useful  interest  to 
contractors. 

AFSCM  375-4,  System  Program  Management  Procedures 

375-4  establishes  the  requirements,  policies,  and  procedures  for  the 
Conceptual,  Definition,  Acquisition,  and  Operational  Phases  of  a  system 
program.  It  prescribes  the  significant  management  activities  for  integrating 
and  fulfilling  the  responsibilities  of  the  organizational  elements  involved  in 
managing  a  system  program.  It  is  the  mandatory  management  standard  for  all 
future  Systems  Command  system  programs  and  projects.  AFSCM  375-4  will 
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NO. 

TITLE 

DATE  OF 
ISSUE 

FOR  CON¬ 
TRACT 
APPLICA¬ 
TION 

REMARKS 

375-1 

CONFIGURATION  MANAGEMENT 
DURING  DEFINITION  AND 
ACQUISITION  PHASES 

1  Jun  64 
Currently 
being  re¬ 
vised 

Yes 

Applies  to  all 

Hardware  and 

Software 

procurements 

375-2 

SYSTEM  PROGRAM  MANAGE¬ 
MENT  SURVEYS  AND  IN¬ 
DUSTRIAL  MANAGEMENT 
ACCOUNTING  SURVEY 

Not  list¬ 
ed  in 
July  65 
Index. 

No 

Used  by  IGs  and 
survey  teams. 

375-3 

SYSTEM  PROGRAM  OFFICE 
MANUAL 

15  Jun  64 

No 

Chatty  discussion 
of  how  a  SPO 
operates. 

375-1* 

SYSTEMS  PROGRAM  MANAGE¬ 
MENT  MANUAL 

Defini¬ 

tion 

Phase 

16  Mar  64 
Currently 
being 
revised 
and  ex¬ 
panded 

No 

Phase  Manual  - 
5  appendices 
covering  each 

Division  of  SPO. 

(flow  chart  and 
narrative) 

375-5 

SYSTEM  ENGINEERING  MAN¬ 
AGEMENT  PROCEDURES 

Interim 
issue 
l4  Dec  64 
Final 
issue  in 
printers 

Yes 

Exhibits  to  be 
followed  liter¬ 
ally;  rest  of 
text  is  guidance 
and  philosophy 

375-6 

DEVELOPMENT  ENGINEERING 

l4  Aug  64 

No 

Bible  of  CMD 
(DCASR)  person¬ 
nel. 

375-7 

SYSTEM  TRAINING  EQUIP¬ 
MENT  MANAGEMENT 

Final 

draft 

being 

reviewed 

Yes 

Used  by  Person¬ 
nel  Subsystem 
managers  and  Air 
Training  Command 

310-1 

MANAGEMENT  OF  CONTRACTOR 
DATA  AND  REPORTS 

15  Mar  64 

Yes 

Vol  I  -  Policies 
and  Responsibil¬ 
ities 

Vol  II  -  Authori¬ 
zed  (standardi¬ 
zed)  Data  List 

Used  on  all  pro¬ 
curements  re¬ 
quiring  data 
(documentation) 
from  contractors 

70- ? 

PREPARATION  OF  WORK 
STATEMENTS 

Final 
draft 
being  co¬ 
ordinated 

Model  Work  State¬ 
ments  .  Each  AFSC 

Division  may 
prepare  a  supple¬ 
ment  to  this  manual. 

Figure  2 

System  Management  Manuals 

AFSCM  375/310  Series 
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never  be  placed  on  contract  as  a  contractual  requirement,  however.  It  Is 
vital  for  contractors  to  be  familiar  with  375-4,  since  this  is  the  "roadmap" 
of  management  and  technical  milestones  and  events  that  a  SPO  will  follow 
on  all  future  contracts.  AFSCM  375-4  is  the  "overall"  AF  systems 
management  manual  and  references  375-1  and  375-5. 

AFSCM  375-1,  Configuration  Management  Manual 

AFSCM  375-1  establishes  the  policy,  guidance  and  the  responsibilities 
for  systerrv/equipment  in  the  management  of  the  configuration  of  system^/ 
equipments.  Itprescribes  the  format  the  details  for  preparation  and  main¬ 
tenance  of  specifications  and  drawings.  It  provides  for  the  control  and 
approval  of  engineering  changes  and  for  implementing  these  decisions.  It 
describes  the  various  engineering  inspections  and  compliance  reviews. 
AFSCM  375-1  is  placed  on  contracts  as  a  contractual  requirement  on  a 
selective  Exhibit  by  Exhibit  basis. 

AFSCM  310-1,  Data  Management  Manual 

Describes  the  overall  data  (documentation)  management  approach, 
control  procedures  and  standards.  3I0-I  is  also  a  catalog  of  approved  data 
(documentation)  items.  Air  Force  organizations  ordering  data  from  contrac¬ 
tors  choose  their  documentation  required  from  this  approved  list.  Selective 
portions  of  AFSCM  310-1  are  placed  on  all  contracts. 

AFSCM  375-5,  System  Engineering  Management  Procedures 

This  is  the  manual  being  described  in  this  paper.  AFSCM  375-5  is  placed 
on  contract  and  becomes  a  contractual  requirement,  selectively,  on  an 
Exhibit  by  Exhibit  basis. 
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SECTION  III 


UNIFORM  DESIGN  PROCESS 

No  two  systems  are  ever  alike  in  their  developmental  requirements. 
However,  there  is  a  uniform  and  identifiable  process  for  logically  arriving 
at  system  decisions  regardless  of  system  purpose,  size,  or  complexity. 

AFSCM  375-5  describes  and  specifies  such  a  process,  i.e.,  a  system 
engineering  management  process.  The  generation  of  a  balanced  system 
design  requires  that  each  major  design  decision  be  based  upon  the  proper 
consideration  of  system  variables  such  as:  facilities,  equipment,  computer 
programs,  personnel,  procedural  data,  training,  logistics,  intrasystems  and 
intersystem  relationships.  All  considerations  must  be  made  within  Jhe  para¬ 
meters  of  time,  cost,  and  performance  as  defined  or  developed  for  the  system. 
This  logical  consideration,  evaluation,  and  selection  of  a  balanced  system 
design  necessitates  the  closest  coordination  of  selected  skilled  personnel 
who  work  as  a  homogenous  system  engineering  design  team.  The  375-5 
system  engineer  uses  methodology  all  engineers  use,  but  does  use  more 
analytical  reasoning  and  attacks  problems  all  at  once,  rather  than  piece¬ 
meal.  Additionally,  the  system  engineer  draws  on  a  wider  experience  and 
a  point  of  view  that  recognizes  functional  similarities.  This  then  enables 
the  organization  of  engineering  contributions. 

Organization  of  AF5C  Manual  375-5 

The  375-5  manual  establishes  and  describes  in  detail  the  Air  Force 
methodology  for  accomplishing  the  system  engineering  management  process. 
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The  main  body  of  the  manual  provides  guidance  and  policy  for  Air  Force 
organizations  and  also  is  very  useful  to  contractors  for  general  information, 
and  an  understanding  of  how  the  government  will  manage  system  engineering. 

The  prime  interest  to  contractors  is  in  the  four  exhibits,  any  one  or  all 
of  which  may  be  placed  on  contract  as  a  specific  contractual  requirement: 

Exhibit  I  describes  the  milestones  and  events  that  should  occur  during  a 
total,  typical  system  engineering  exercise. 

Exhibit  II  describes  in  detail  the  documentation  (data)  that  must  be 
prepared  by  the  contractor. 

Exhibit  III  is  used  only  on  major  programs  and  presents  a  method  for  con¬ 
ducting  the  analysis  of  maintenance  functions  utilizing  automated  mainten¬ 
ance  documentation. 

Exhibit  IV  details  the  responsibilities  of  the  contractor,  the  government, 
and  the  not-for-profits  during  a  system  engineering  management  exercise. 

The  375-5  manual  incorporates  the  requirements  of  the  following  documents: 

MIL-D-9310B  (USAF)  Data  for  Aeronautical  Weapon  Systems  and  Support 
Systems. 

MIL-W-94IIA  (USAF)  Weapon  Systems,  Aeronautical  General  Specification 
for 

MIL-D-94I2D  (USAF)  Data  for  Aerospace  Ground  Equipment  (AGE) 
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SECTION  IV 


FUNDAMENTAL  CYCLE  OF  THE  SYSTEM  ENGINEERING  PROCESS 

The  cycle  shown  pictorially  in  Figure  3  describes  the  four  fundamental 
steps  in  the  AFSCM  375-5  system  engineering  process.  The  process  is  a 
tool  for  designing  the  system  on  a  total  basis  so  that  the  design  will  reflect 
considerations  of  requirements  for  equipment,  computer  programs,  facilities, 
procedural  data,  and  personnel  in  an  integrated  fashion.  It  provides  the 
source  requirement  data  for  the  development  of  specifications,  test  plans, 
and  procedures;  and  the  backup  data  required  to  define,  contract,  design, 
develop,  produce,  install,  checkout,  and  test  the  system. 

The  system  engineering  process  identifies:  (l)  AF  system  objectives, 

(2)  the  "design  to"  requirements  necessary  to  meet  these  objectives, 

(3)  the  "build  to"  requirements  which  prescribe  the  ultimate  configuration 
of  the  system  to  be  delivered  to  the  user,  and  (4)  the  requirements  for 
personnel,  training,  procedural  data,  and  logistics  support.  System 
engineering  is  initiated  in  the  latter  part  of  the  Conceptual  Phase,  through 
the  Definition  and  Acquisition  Phases,  and  early  into  the  Operational  Phase 
of  the  375-4  system  life  cycle  described  earlier. 

The  two  fundamental  purposes  of  the  system  engineering  management 
process  are:  (I)  to  establish  a  single  analysis,  the  definition,  the  trade¬ 
off,  and  the  synthesis  of  requirements  and  (2)  to  provide  a  clear  and 
concise  reference  source  for  selected  system  design  solutions,  for  common 
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STEP  1 


STEP  2 


STEP  4 


Figure  3 

Fundamental  Cycle  of  the  System 

Engineering  Process 


use  by  the  various  AF  organizations,  between  the  AF  and  the  contractors, 

and  between  contractor  organizations.  The  single  reference  source  will 

be  evolved  in  consonance  with  the  design  process  and  will  be  the  basis  for 

the  identification,  control,  and  accounting  of  the  system  by  means  of  con- 
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figuration  management  procedures  specified  in  AFSCM  375-1. 

Step  One 

The  first  step  of  the  AFSCM  375-5  process,  shown  pictorially  in 
Figure  3,  is  begun  by  either  the  Air  Force  or  with  the  help  of  a  not-for- 
profit  contractor,  and  consists  essentially  of  translating  the  military 
requirements  into  basic  functional/technical  requirements.  These  written 
requirements  are  then  presented  in  a  pictorial  form  identified  as  Functional 
Flow  Block  Diagrams  and  are  useful  in  portraying  the  sequential  and  parallel 
interactions  of  functions.  At  this  point  hardware,  circuits,  or  devices  are 
not  mentioned,  the  significant  characteristic  is  a  functional  design. 

Examples  of  a  top  level  Functional  Diagram  for  an  electronic  system 
might  be: 

(1)  Detect  and  track  all  space  objects  within  defined  zone  of 
apprehension. 

(2)  Identify  mission  of  each  object,  compute  apparent  track  and  target, 
compose  and  dispatch  warning  messages  and  information  concerning 
available  protective  measures. 

(3)  Display  continuous  status  of  space  objects  and  defensive  weapons 
and  provide  display  of  other  pertinent  data  when  called  for. 
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The  above  is  an  example  of  gross  "operations  functions"  which  then 
would  be  supported  by  "maintenance  functions,  "  11  test  and  activation" 
functions,  and  "production"  functions.  Once  the  gross  functions  have  been 
evolved,  accepted  by  the  Air  Force  as  appropriate,  the  system  requirements 
can  now  be  translated  into  sub-functions,  which  are  the  next  level  of 
expansion  of  the  system  functions. 

The  format,  editorial  style,  and  the  standardized  visual  presentation  of 
these  top  and  first  level  Functional  Flow  Block  Diagrams  is  detailed  in 
AFSCM  375-5.  The  basic  objective  of  these  diagrams  is  to  develop  a 
first  hypothesis  for  helping  to  mold  the  eventual  solution.  They  are  also 
important  in  accomplishing  interfaces  between  contractors,  since 
diagrams  are  essentially  drawings  to  be  approved  and  released  internally 
within  a  contractor's  facility  in  the  same  manner  as  engineering  drawings. 

Step  Two 

The  second  step  of  the  AFSCM  375-5  process  is  to  translate  the  functions 
detailed  in  the  Flow  Block  diagrams  into  design  requirements.  The  design 
requirements  are  those  such  as  input,  output,  tolerances,  safety,  main¬ 
tainability,  reliability,  etc.,  that  provide  the  criteria  for: 

a.  designing  equipment  anchor  computer  programs 

b.  defining  equipment  facility 

c.  defining  intersystem  interfaces 

d.  determining  requirements  for  personnel,  training,  training  equipment, 
and  procedural  data. 
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The  design  requirements  at  this  time  are  officially  and  formally  recorded 
on  Requirements  Allocation  Sheets,  as  shown  in  Figure  4.  The  specific 
instructions  for  these  sheets  are  described  in  detail  in  AFSCM  375-5.  In 
essence,  the  completed  Requirements  Allocation  Sheets  will  provide  the 
"what"  and  "why"  of  every  function,  answering  the  questions:  Why  is 
the  function  necessary?  Why  should  the  functions  be  accomplished  at  this 
point  in  the  sequence  of  activities?  What  engineering  characteristics  of 
this  function  are  related  to  engineering  characteristics  of  another  function? 

Step  Three 

The  third  fundamental  step  shown  in  Figure  3  consists  of  systerr/design 
engineering  studies  which  are  performed  concurrently  with  Step  2  and 
Step  4  to: 

a.  determine  the  selection  of  alternate  functions  and  functions  sequence 

b.  determine  the  design,  personnel,  training,  and  procedural  data 
requirements  imposed  by  the  functions 

c.  determine  the  best  way  to  satisfy  the  design  requirements,  and 

d.  select  the  best  design  approach  for  integrating  the  design 
requirements  into  the  various  hardware  items  of  equipment  and/or 
computer  programs 

Step  3  permits  the  design  approach  to  be  detailed  to  the  point 
necessary  to  satisfy  the  requirements  that  were  listed  on  the  Requirements 
Allocation  Sheets  (Step  2).  Trade-off  studies  are  now  effected  and  are 
recorded  in  Trade  Study  Reports  (format  and  content  detailed  in  AFSCM 
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375-5).  Trade  Study  Reports  contain,  as  a  minimum,  extracts  from 
designer's  notebooks,  contractors  internal  memorandums,  minutes  of 
meetings,  reductions  of  charts  and  formal  engineering  reports,  etc. 

Study  reports  contain  possible  design  approaches,  the  identification  of 
significant  design  characteristics  of  each  design  approach,  the  impact  of 
the  design  on  cost,  reliability,  maintainability,  personnel,  etc., 
comparison  of  design  approaches.  Finally,  there  will  be  selection  of  a 
design  approach  with  substantiation  for  the  choice.  The  reasons  will  be  in 
the  form  of  Schematic  Diagrams,  outline  drawings,  interface  details, 
reliability  data,  and  other  backup  data. 

Step  Four 

The  primary  activity  in  this  step  is  the  development  of  a  Design  Sheet 
(per  AFSCM  375-5)  which  will  define  sufficiently  detailed  engineering 
information  utilizing  numerical  values  (quantitative  reliability  require¬ 
ments  for  example)  with  associated  tolerances  to  provide  criteria  for  the 
detail  design,  development  and  test  of  the  contract  end  items.  The 
Design  Sheet  documents  the  "design  to"  and  "test  to"  requirements  and 
subsequently  becomes  part  of  the  Detail  Specification  (AFSCM  375-1). 
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SECTION  V 


ITERATION  OF  THE  SYSTEM  ENGINEERING  PROCESS 

Having  completed  the  fundamental  cycle  of  the  system  engineering 
process,  and  upon  documenting  the  results  in  "top"  and  "first"  level 
Functional  Flow  Block  Diagrams,  Requirements  Allocation  Sheets, 
Trade  Study  Reports,  and  Design  Sheets,  the  second  level  functions 
are  identified  and  the  fundamental  process  is  repeated.  The  same 
procedure  is  repeated  at  any  additional  levels  required  to  define  and 
design  the  system.  Some  functions  may  not  require  separate  diagram 
levels  and  may  be  included  in  a  higher  level  diagram.  There  are 
interactions  and  feedbacks  between  levels  as  the  cycle  is  repeated. 
Detailed  examples  are  provided  in  AFSCM  375-5. 
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SECTION  VI 


IMPLEMENTING  SYSTEM  ENG INEERING  MANAGEMENT 

Industry-Air  Force  Guidance 

Step-by-step  procedures  that  are  to  be  followed  by  both  the  SPO  and 
the  contractor  are  described  in  Exhibit  I  of  AFSCM  375-5.  These  procedures 
essentially  consist  of  a  detailed  flow  chart  which  identifies  the  sequential 
activities  on  a  relative  time  basis,  beginning  with  the  issuance  of  the 
Hq  USAF  requirement  and  extending  through  the  early  part  of  the 
Operational  Phase.  This  diagram  portrays  the  system  engineering 
activities  to  be  accomplished  by  the  Air  Force  System  Program  Office, 
the  contractors,  and  the  not-for-profits  (MITRE  Corp.,  Aerospace  Corp., 
System  Development  Corp.,  etc.).  The  activity  diagram  also  identifies 
the  required  system  engineering  documentation  and  prescribes  the  relation¬ 
ships  between  documentation,  engineering,  design  reviews,  specifications, 
design  baselines,  and  the  major  commitment  points.  This  is  the  first  time 
that  a  formalized  detailed  roadmap  of  engineering  management  activities 
has  been  provided  to  contractors.  Formal  points  for  Air  Force  management 
review  of  the  system  as  it  is  being  defined,  designed,  and  developed  are 
provided. 

The  Activity  Flow  Diagram 

The  activity  diagram  is  highly  detailed  and  portrays  106  activities  that 
would  normally  be  performed  by  the  Air  Force  and  the  contractors.  In 
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some  instances,  selective  use  of  only  those  activities  considered 
necessary  to  a  particular  program  would  be  imposed  on  contractors,  however, 
the  106  activities  might  conceivably  be  increased  as  well.  Figure  5  portrays 
a  small  section  of  the  system  engineering  activity  flow  diagram.  It  will  be 
noted  that  the  square  blocks  are  primarily  government  responsibilities, 
while  the  octagonal  blocks  are  primarily  contractor  responsibility.  The  flow 
shows  a  Specification  Line,  a  System  Design  Line,  and  Operations  Design 
Line,  a  Maintenance  Design  Line,  and  a  Test  Support  Line  with  each 
line  showing  the  major  interacting  activities  required  in  conducting  system 
engineering.  It  is  possible,  as  an  example,  to  go  from  left  to  right  and 
follow  the  entire  gamut  of  specification  activities  and  note  their 
relative  time  sequence  to  all  the  other  activities.  The  circled  numbers 
appearing  below  each  block  identify  the  documentation  associated  with 
the  block.  There  is  a  continual  interaction  between  lines  of  activities 
and,  while  the  activities  appear  as  step  functions,  they  are  in  fact  points 
on  a  continuum. 

System  Engineering  Documentation 

5 

As  recently  stated  by  General  B.  Schriever,  "Decisions  are  the  basis 
of  management  and  data  (documentation)  are  the  basis  of  all  decisions.  " 

The  identification,  definition,  and  specification  of  the  system  engineering 
effort  and  the  system  requirements  is  accomplished  on  a  progressive  and 
formalized  basis.  Documentation  is  the  basis  and  the  product  of  the  design 
effort.  AFSCM  375-5  (and  AFSCM  310-1)  establishes  detail  documentation 
procedures  that  insure  effective  utilization  in  accomplishing  design  reviews. 
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making  engineering  decisions,  for  developing  specifications  and  drawings, 
for  controlling  changes,  for  making  management  decisions,  and  to  insure 
logistics  and  maintenance  compatibility. 

As  was  earlier  described.  Design  Sheets,  Functional  Flow  Block 
Diagrams,  Requirements  Allocation  Sheets  and  Trade  Study  Reports  are 
utilized  in  the  375-5  process  to  serve  as  the  basic  documentation  against 
which  engineering  evaluations  during  the  Definition  Phase  are  accomplished. 
Much  of  this  data  is  incorporated  into  Detail  Specifications  which  are  then 
used  as  the  basis  for  conducting  the  engineering  inspections  during  the 
Acquisition  Phase.  Additionally,  this  data  is  used  by  the  PERT/Cost 
activities,  for  procurement  action,  and  as  the  basis  for  test  planning. 

Of  prime  importance  is  the  development  of  logistics  support  requirements 
for  the  program.  The  data  of  particular  use  here  is  prepared  as  End  Item 
Loading  Documentation.  It  is  vital  that  reaction  times,  maintenance  down¬ 
time,  and  maintenance  functions  be  considered  in  determining  design 
requirements  and  selecting  the  design  approach.  Personnel  Utilization 
Sheets,  as  an  example,  identify  the  maintenance  personnel  effort  by 
specific  maintenance  location. 

AFSCM  375-5  specifies,  details,  and  furnishes  the  format  for  an 
imposing  array  of  documentation.  The  objective  is  to  insure  a  for- 
matized  and  formalized  control  of  the  total  system  engineering  effort. 
However,  the  use  of  system  engineering  documentation  will  vary  upon 
the  specific  nature  of  a  system  or  project.  AFSCM  375-5  describes  the 
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minimum  documentation,  however,  the  total  extent  of  maximum  documen¬ 
tation  is  subject  to  agreement  between  the  AF  and  the  contractor  and  will 
vary  depending  on  the  procurement  requirement. 

Comparison  of  Industry  &  Government  Approach 

The  difference  between  past  industry  practice  and  the  375-5  requirements 
is  primarily  the  degree  of  formalization  within  a  logically  developed  frame¬ 
work.  With  375-5,  the  main  elements  are  laid  out  in  advance  so  that  they 
are  understood  not  only  by  the  contractor  with  respect  to  the  job,  but 
the  customer  as  well.  It  is  essentially  an  agreement  between  the  two 
parties  who  have  engaged  in  the  contract  as  to  what  they  expect  to  get, 
in  considerable  detail,  at  a  fairly  early  point  in  time.  This  agreement — 
and  its  controls — is  progressively  definitized  as  the  system  is  defined. 

Then  there  is  a  demonstration,  as  the  equipment  evolves,  to  show  that  the 
contractor  has  in  fact  achieved  what  was  agreed  upon.  It  will  then  be 
possible  to  look  at  the  dollars,  to  look  at  the  schedule,  and  by  proper 
testing  determine  whether  the  contractor  has  been  successful  in  producing 
the  product  that  was  intended.  With  some  of  the  past  systems  programs, 
this  was  done  but  not  in  the  same  formalized  manner.  One  reason,  in  part, 
was  that  the  contractor  was  delving  in  an  area  where  he  wasn't  certain 
of  the  end  results,  and  the  customer  was  never  too  certain  of  the  operational 
use  of  the  device  after  he  received  it.  The  customer  frequently  did  not 
establish  the  specific  philosophy  of  operation  and  maintenance  until  after 
the  system  was  developed.  Consequently,  many  changes  occurred  in 
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order  to  satisfy  the  basic  operational  requirements.  In  the  past  several 
years,  both  contractors  and  customers  alike  have  gained  considerable 
experience  and  this  experience  is  now  being  reflected  in  Air  Force 
regulations  and  manuals. 

In  order  for  the  contractor  to  be  totally  responsive  to  the  Air  Force, 
the  contractors  organization  should  in  effect  parallel  the  customers 
organization.  The  contractors  project  manager  would  have  a  group  of 
deputies  reporting  to  him,  covering  essentially  the  same  areas  as  the  five 
deputies  reporting  to  the  Air  Force  System  Program  Office  (SPO)  director. 
The  only  area  difficult  to  mirror  is  production. 

Organization  for  System  Engineering  Management 

Figure  No.  6  shows  the  typical  AF  System  Program  Office 
organization  and  the  overall  relationship  of  the  various  system 
management  manuals.  This  is  the  type  of  organizational  structure  that 
some  contractors  utilize  and  that  would  best  assure  compatibility  with 
the  SPO  organization. 


25 


Figure  6 

System  Program  Office  Organization  and  the  Overall  Relationship 
to  the  AFSC  Systems  Management  Manuals 


SECTION  VII 


SUMMARY  OF  SYSTEM  ENGINEERING  PROCESS 

AFSCM  375-5  establishes  the  requirements  for  step-by-step  procedures 
to  be  followed  in  implementing  system  engineering  management  during 
the  latter  part  of  the  Conceptual  Phase,  through  the  Definition  and 
Acquisition  Phases,  and  the  early  part  of  the  Operational  Phase.  It 
specifies  the  required  system  engineering  documentation  and  prescribes 
the  relationships  between  documentation,  engineering,  design  reviews, 
specifications,  baselines  and  major  commitment  points. 

The  375-5  manual  has  for  the  first  time  developed  a  sequential 
activity  diagram  on  a  relative  time  phase  base  beginning  with  the 
issuance  of  military  requirements  and  extending  into  the  Operational 
Phase.  This  diagram  portrays  system  engineering  activities  to  be 
accomplished  by  the  military  agency,  the  not-for-profits,  and  the  contractors. 

The  new  Air  Force  System  Engineering  Management  Process  significantly 
affects  the  policy,  technical,  and  management  procedures  and  practices 
under  which  all  future  systems  will  be  acquired.  This  process  integrates  all 
of  the  technical  and  support  disciplines  into  a  total  engineering  process. 

System  Engineering  will  specify  the  hardware,  the  computer  programs, 
facilities,  personnel,  training,  and  the  procedural  data  required  to  meet 
AF  system  mission  requirements.  The  objective  is  to  get  a  job  done  that  is 
technically  correct,  at  minimum  cost,  and  within  the  scheduled  time  period. 
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375-5  system  engineering  management  is  a  technique  that  establishes 
a  plan  and  enables  the  system  manager  to  know  where  he  stands  with  regard 
to  that  plan.  The  entire  375-5  concept  is  to  define  a  task,  determine  a 
course  of  action,  make  available  the  tools  to  properly  carry  out  that  course 
of  action,  act,  monitor,  and  respond  accordingly. 

"System  Engineering  Management  has  evolved  into  a  corporate  tool,  as 
essential  as  any  facet  of  technology.  It  is  intended  to  eliminate  fumbling 
and  mistakes — remove  the  need  for  putting  out  unforeseen  'fires' — by 
careful,  professional  planning.  Vital  and  hard  to  come  by  dollars  are 
saved  because  problems  are  anticipated  and  avoided.  It  is  a  tool  that  can 
minimize  the  annoying  and  frustrating  'paper  mill'  associated  with  complex 
systems  by  cutting  down  on  data  requirements  and  eliminating  duplication.  " 

It  has  not  been  possible  to  treat  the  subject  of  Air  Force  System 
Engineering  Management  exhaustively  in  this  paper.  System  engineering 
as  such  has  been  used  on  a  wide  scale  by  both  industry  and  the  government. 
In  the  government,  the  Air  Force  Ballistic  Systems  Division  and  the  MITRE 
Corp.  (a  not-for-profit)  both  have  extensive  experience  and  background 
in  this  subject.  This  background  and  experience,  plus  other  concerted 
studies,  have  evolved  the  procedural  technique  described  herein. 

AFSCM  375-5  is  therefore  essentially  the  composite  experience  of  both 
industry  and  government  and  is  expected  to  result  in  systems  that  meet  the 
stringent  Air  Force  requirements  of  time,  cost  and  performance. 
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